Multihoming is the configuration of multiple Internet Protocol (IP) addresses on a device participating in an IP network. Multihoming may be accomplished through different approaches, including assigning multiple IP addresses to a single link and employing multiple physical interfaces with distinct IP addresses. Multihoming may be used to split data into parallel streams, so as to increase throughput and reliability. For example, a data stream may be received at a host over three parallel streams over three distinct IP addresses over three distinct links. The received data may then be recombined at the host.
In the context of IP version 6 (IPv6), the Internet Engineering Task Force (IETF) Shim6 protocol may be employed to facilitate multihoming. Shim 6 is host-based, and offers features such as the ability to manage several IP paths, failure detection and recovery, and best path selection. In IP version 4 (IPv4) multihoming, address prefixes were required, which increased the size of routing tables and, consequently, the time required to deliver packets. Using Shim6 and IPv6, the address prefixes are not required, thereby avoiding the performance delays of IPv4 multihoming.
Shim6 works by modifying the network layer in the protocol stack. When two hosts using Shim6 connect, they establish a Shim6 context and exchange information including the multiple IPv6 addresses with which they may be reached. During transmission of a packet, the packet is received at the network layer in the transmitting host from a higher layer with a destination IP address of the intended recipient host. The Shim6 element in the network layer may substitute a different IP address for the destination host, and then communicate the packet up to the transport layer. This substitution may be performed if, for example, the destination IP address originally indicated in the packet identifies a link to the destination host that is no longer viable. This allows for the new path to be used without breaking current transport-layer configurations. In Shim6, the IP addresses revealed to the transport layer are referred to as “identifiers,” while the IP address revealed to the network and data link layers are referred to as “locators.” The Shim6 element stores mappings between identifiers and locators in order to facilitate path selection.
FIG. 1 shows an example of two hosts configured to communicate using Shim6. In State A 150, Host A 190 and Host B 192 configured to communicate using a first link 120. Using Shim6, Host A 190 and Host B 192 can transition to State B 152, where Host A 190 and Host B 192 communicate using a second link 130. Host A 190 is connected to two Internet Service Providers (ISPs), ISP1 102 and ISP2 104. Host A 190 is multihomed, and is allocated a first IP address (ISP1.A) by ISP1 102 and a second IP address (ISP2.A) by ISP2 104. Host A 190 is connected to the Internet 106 via ISP1 102 and ISP2 104. Host B 192 is connected to ISP3 108, and is connected via ISP3 108 to the Internet 106. Host B 192 is allocated an IP address (ISP3.B) by ISP3 108. In State A 150, Host A 190 and Host B 192 communicate using link 120, which operates through ISP1 102 and ISP3 108. At State A 150, the network layer in the protocol stack at Host B 192 may receive packets from the transport layer addressed to Host A 190 at either the ISP1.A or the ISP2.A address. If the packet is addressed to ISP2.A, the Shim6 layer at Host B 192 may decide to change the packet headers to indicate that the destination is ISP1.A, and may pass the modified packets to the data link layer for communication over the first link 120. The transport layer at Host B 192 is unaware of which address is used to actually communicate the packets to Host A 190, as this is handled by the Shim6 sub-layer. If the first link 120 becomes unusable, Host A 190 and Host B 190 transition to State B 152 and communicate using a second link 130. At State B 152, the network layer in the protocol stack at Host B 192 may receive packets addressed to Host A 190 at either ISP1.A or ISP2.A. If the packet is addressed to ISP1.A, the Shim6 layer at Host B 192 will re-address the headers to ISP2.A. The transition from State A 150 to State B 192 does not require reconfiguration of transport layer resources at either Host A 190 or Host B 192, as operation of the transport layer is unaffected by the transition. Procedures provided by Shim6 for detecting link failure and for performing transitions between links (such as the transition between State A 150 and State B 152) are described in detail below with reference to FIGS. 2 and 3.
Shim6 defines a Forced Bidirectional Detection (FBD) procedure for detecting link failure. FBD is used to determine the viability (or “reachability”) of a used IP address pair between two hosts. Reachability is analyzed in terms of reciprocal traffic; traffic in one direction creates an expectation of traffic in the return direction. The FBD procedure begins after two nodes have successfully established a Shim6 context. A node which implements FBD uses two timers: (1) a send timer to indicate the time since the last packet was sent, and (2) a keepalive timer to indicate the time since the last packet was received. These two timers are mutually exclusive, so that no more than one timer is running at any time. When a host generates an outgoing data packet within the Shim6 context, the send timer is started. If there is a keepalive timer running at the time, the keepalive timer is stopped. When the host receives an incoming data packet, the send timer is stopped and the keepalive timer is started. If the keepalive timer exceeds a keepalive timeout value, a keepalive packet is transmitted to the other host. If the send timer value exceeds a send timeout value, the host determines that the other host is unreachable. Using FBD, it may take the host tens of seconds to determine if the other host is unreachable.
FIG. 2 is a signal diagram showing the FBD procedure. Host A 290 and Host B 292 have established a Shim6 context. Host A starts 202 its send timer and transmits 204 a data packet to Host B 292. Host B 292 starts 206 its send timer and transmits 208 a data packet to Host A. In response to receiving the data packet, Host A 290 stops 210 its send timer and starts its keepalive timer. The keepalive timer of Host A 290 expires 212, and Host A 290 starts 212 its send timer and sends 214 a keepalive packet to Host B 292. In response to the keepalive packet, Host B 292 stops 216 its send timer. Host B 292 starts 218 its send timer and sends 220 a data or keepalive packet to Host A 290. In response to receiving the data or keepalive packet, Host A stops 222 its send timer. At this point, both Host A 290 and Host B 292 determine that the link over which they have been communicating is viable.
Host A 290 then starts 224 its send timer and sends 226 a data or keepalive packet 226. The data or keepalive packet does not reach Host B 292. The send timer of Host B 292 expires 228, indicating a failure of the link to Host A 290. The send timer of Host A 290 expires 232, indicating a failure of the link to Host B 292. At this point, both Host A and Host B have determined that the link over which they have been communicating is broken.
Shim6 further defines the Locator Pair Exploration procedure, which is used by hosts to explore a viable link when they experience link failure. According to the Locator Pair Exploration procedure, the host that first detects a link failure sends probe messages to the other host using different address pairs. The host iterates through address pair combinations until it receives a probe message back. The responding probe message confirms that the initial probe message has reached the other host, and that the link is functional in both directions.
FIG. 3 is a signal diagram showing the Locator Pair Exploration procedure. At Host B 392, the send timer expires 302, indicating a failure on the link being used to communicate between Host A 390 and Host B 392. Host B 392 then sends 304 a probe request on the link defined by the IP address pair (B1, A1). The probe request includes a field indicating an “exploring” state. The probe request does not reach Host A 390. Host B 392 then sends 306 a probe on the link (B2, A1). The probe does not reach Host B 390. Host B 392 then sends 308 a probe request to Host A 390 on the link (B2, A2). This probe reaches Host A and is received by Host A. In response to receiving the probe, Host A 390 sends 310 a return probe on link (A2, B2). The return probe has a filed indicating a state of “inboundok.” The return probe reaches Host B and is received by Host B. In response to the return probe, Host B 392 sends 312 a probe with a state of “operational” to Host A. The “operational” probe reaches Host A 390 and is received by Host A. At this time, Host A 390 and Host B 392 have established a viable link using the IP address pair (B2, A2). Host A may then send 314 a data packet to Host B on link (A2, B2).
Institute of Electrical and Electronics Engineers (IEEE) 802.21 MIH (Media Independent Handover) defines a framework for supporting mobility of devices between networks based on heterogeneous link layer (layer one and layer two) technologies. MIH defines mechanisms for handover and link adaptation in response to changing link conditions and quality of service (QoS) requirements. MIH specifies an MIH Function (MIHF), which is an implementation of MIH services and is treated as a logical entity implemented in both MIH devices and in the network.
FIG. 4 shows an example protocol stack 450 that includes an MIHF 400. The MIHF 400 implements three MIH services: the Media Independent Event Service, the Media Independent Information Service (MIIS), and the Media Independent Command Service (MICS). The Media Independent Event service relates to the notification of events such as physical, data link and logical link layers state changes and establishment and tearing down of links. The MIHF provides these services to the MIH Users 404, which are upper layer (layer three and above) entities.
The protocol stack 450 includes a first link layer component 420 that implements media-specific link layer functionality according to a first radio access technology (RAT). A second link layer component 430 implements media-specific link layer functionality according to a second RAT. As an example, the first link layer component 420 may function according to IEEE 802.11 Wireless Local Area Network (WLAN) standards, while the second link layer component 430 may function according to Third Generation Partnership Project (3GPP) Evolved Universal Terrestrial Radio Access Network (E-UTRAN) standards.
In MIH, exchanges of information between functional entities occur via Service Access Points (SAPs). The MIH Users 404 may communicate with the first link layer component 420 via a first Logical Link Control (LLC) SAP 406 and with the second link layer component 430 via a second LLC_SAP 408. The MIHF 400 and the MIH Users 404 communicate using MIH_SAP 402. The MIHF 400 and the first link layer component 420 communicate via MIH_LINK_SAP 410. The MIHF 400 and the second link layer component 430 communicate via MIH_LINK_SAP 418. Each MIH_LINK_SAP 410, 418 may be implemented as a media-specific Media Access Control (MAC) SAP, physical layer (PHY) SAP, and/or Logical Link Control (LLC) SAP.
The first link layer component 420 may notify the MIHF 400 of a change in MAC or PHY state via the MIH_LINK_SAP 410, and the MIHF 400 may subsequently communicate a notification of the event to the MIH Users 404 via the MIH_SAP 402. The MIHF 400 may additionally communicate with remote MIHFs (not depicted) via a network SAP (MIH_NET_SAP) and receive event notifications from the remote MIHFs regarding, for example, the detection of new access networks and link QoS information.
The purpose of the MIIS is to acquire a global view of available networks to facilitate network selection and handovers. The MIIS provides a mechanism for the exchange of information between MIH devices and MIH-capable networks regarding handover candidates. MIIS information may be communicated in both directions on the MIH_SAP 402 as well as in both directions on the MIH_LINK_SAPs 410, 418.
The MICS allows for the initiation of handover between links. Using the MICS, handover commands are received at the MIHF 400 from MIH Users 404 via the MIH_SAP 402. In response to a handover command, the MIHF 400 may issue a command to control lower layer entities. For example, the MIHF 400 may communicate with the first link layer component 420 and the second link layer component 430 in order to handover the protocol stack 450 from one network to another.
While current technologies such as MIH and Shim6 provide mechanisms for improving the connectivity of networking devices, current technologies leave a number of issues unaddressed. Current power-saving techniques for single- and dual-mode wireless devices determine when radio interfaces are turned on and off based on parameters such as link quality and required QoS. However, these techniques do not suggest how power-saving techniques may implemented in multimode, multihoming devices. Additionally, current technologies do not suggest how handover should be performed for multimode, multihoming devices. For example, current technologies do not provide solutions that consider both access network characteristics and multihoming IP path characteristics in making handover decisions. Therefore, technologies for power-saving and IP link/access network mobility in the context of wireless devices with multiple radio interfaces are required.